Conversation
There was a problem hiding this comment.
LGTM.
On adding vim.docs. I can see it being useful. On our side, obviously, for adding documentation for plugins. Even as a user, were it exposed, it might be good as it could still generate a man page, even if it doesn't go to ndg. This would allow for self-documentation when users expose their nvf config as a package, for example (if we do decide to make it generate a man page).
In the meantime, I don't see blockers for this PR if you want to merge and handle docs in another one, so I'll drop an approval
In Nixpkgs, the modules can specify documentation bits under |
NotAShelf
force-pushed
the
notashelf/push-qozvyzsvqtmk
branch
from
09bd743 to
f3280eb
Compare
Signed-off-by: NotAShelf <raf@notashelf.dev> Change-Id: I5f5f576642884c09a8e4afc18499ed606a6a6964
Signed-off-by: NotAShelf <raf@notashelf.dev> Change-Id: I9b04107496df27dcda1a24ce000da3f46a6a6964
NotAShelf
force-pushed
the
notashelf/push-qozvyzsvqtmk
branch
from
f3280eb to
1476d4c
Compare
|
Still not ready for a merge, but I'd appreciate an updated review. |
3 participants
This is an internal refactor that aims to be non-breaking as much as possible. There are two changes, with a few more on the way:
vim.filetypeAPI that can be used to register custom filetypes usingvim.filetype.add(). This is placed in the DAG hierarchy beforelazyConfigsso it's possible to use the API to register custom filetypes that then get used to lazy-load a plugin on FT.neovim/mappingstoneovim/init/mappings.nixsince the neovim/init module is where I've decided to consolidate core Neovim options. This is no longer "init" only, so it'll be renamed in a later PR or on the master branch. Not a breaking change.This PR has been inspired by, and aims to support, #1304 so I'll be adding
vim.ftpluginandvim.ftdetectoptions as auxiliary module options that the per-language indents can be use with.Last but not least, I'll go over existing core options and extend options or documentation where applicable. Also CC @horriblename and @Soliprem on something I am not quite sure about: I'd like modules to be able to create their documentation bits to create per-plugin pages, and while NDG does allow this, I am not sure what the API would look like. Should we create a
vim.docsmodule that defines the pages? Is leaking documentation sources to user-space a waste of space?